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(57) ABSTRACT 

A communications adapter is provided for interfacing 
between a master device and an I/O device (body) having an 
output and/or an input. In the case of the I/O body having an 
output, the adapter has a TCP port for coupling to the master 
device via a transmission path for receiving a request 
message. The adapter also has a connector for operable 
coupling to the I/O device for receiving the output of the I/O 
device. The adapter further has an interface circuit operably 
connected to the TCP port and the connector for transmitting 
a response message over the transmission path in response 
to the request message, the response message correlating to 
the output received from the I/O device. The request mes- 
sage and the response message is limited to a length that is 
less than a TCP transaction length and/or a maximum 
transmission unit limit, or both, depending on the embodi- 
ment of the present invention. 

A method is also provided to create a connection between a 
master device and an I/O device having an output and/or and 
input. In the case of the method for providing a connection 
between a master device and an I/O device having an output, 
the method includes receiving over a transmission path a 
request message on a preregistered TCP port selected from 
a plurality of TCP ports. The method also includes receiving 
the output from the I/O device. The method further includes 
transmitting a response message over the transmission path 
in response to the request message, the response message 
correlating to the output of the I/O device. The request 
message and/or the response message is limited to a length 
that is less than both a TCP transaction length and/or a 
maximum transmission unit limit, or both, depending on the 
embodiment of the present invention. 



18 Claims, 3 Drawing Sheets 
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SYSTEM FOR A MODULAR TERMINAL mation software running thereon. For example, U.S. Pat. No. 

INPUT/OUTPUT INTERFACE FOR 5,611,059 discloses various types of controllers within a 

COMMUNICATING MESSAGING control structure for interfacing with the field devices, as 

APPLICATION LAYER OVER ENCODED well as user interface of a personal computer having indus- 

ETHERNET TO TRANSPORT LAYER 5 trial automation software running thereon. 

The communications adapter is for providing an interface 

DESCRIPTION between a master device and an I/O device (body) having an 

This application contains a Microfiche Appendix consist- ° ut P ut ™<V°[ 30 ^ In * e „ case ° f lbe "° bod y ^ avin 8 80 

ing of 1 microfiche and 44 frames. „ ° ut P m > ada P ter has a TCP P° rt for °° u P lm 8 to master 

10 device via a transmission path for receiving a request 

TECHNICAL FIELD message. The adapter also has a connector for operable 

coupling to the I/O device for receiving the output of the I/O 

The present invention relates to input and output (I/O) device. The adapter further has an interface circuit operably 

terminal interfaces for communication between input and connected to the TCP port and the connector for transmitting 

output field devices, and programmable logic controllers 15 a response message over the transmission path in response 

(PLCs), and for communication between input and output to we request message, the response message correlating to 

field devices, and other field master devices, such as a host me output received from the I/O device. The request mes- 

device. More specifically, the present invention relates to a sage m ^ me response message is hmited to a length that is 

modular I/O terminal interface for communication over \ tss trjan a TCP transaction length and/or a maximum 

MODBUS encoded Ethernet to TCP. 20 transmission unit limit, or both, depending on the embodi- 
ment of the present invention. 
The present invention also includes a method for provid- 

Within industrial automation systems market, there are ing a connection between a master device and an I/O device 

various types of communications network protocols which having an output and/or and input. In the case of the method 

were developed for products, such as PLCs, to run on the 25 for providing a connection between a master device and an 

products to be networked together, and for the field devices I/O device having an output, the method includes receiving 

to be monitored and controlled from various locations within over a transmission path a request message on a preregis- 

the particular automation systems. Thus, various types of tered TCP port selected from a plurality of TCP ports. The 

input and output communications devices have been pro- method also includes receiving the output from the I/O 

duced to communicate within the various types of commu- 30 device. The method further includes transmitting a response 

nications protocols for the various types of communications message over the transmission path in response to the 

networks for the automation systems. For example, FIG. 2 request message, the response message correlating to the 

shows various types of communications protocols, such as output of the I/O device. The request message and/or the 

Interbus-S, Profibus DP, Modbus Plus, Echelon, Seriplex, response message is limited to a length that is less than both 

CAN DeviceNet, CAN SDS, and CANCAL, to name only 35 a TCP transaction length and/or a maximum transmission 

a few. An additional protocol is FIPIO. Each of these various unit limit, or both, depending on the embodiment of the 

communications network types require specific input and present invention. 

output devices for communication with the input and output [ n me case of the method for providing a connection 

field devices based on the various types of communications between a master device and an I/O device having an input, 

protocols each having specific and different communications me me thod includes receiving over a transmission path a 

requirements. request message on a preregistered TCP port selected from 

In addition, not only does each network protocol require a plurality of TCP ports. The method also includes- 

different input and output communication devices for com- transmitting a response message over the transmission path 

munication with the various above protocols, but there is 4g in response to the request message. The method further 

also the need of having input and output communication includes transmitting data to the input of the I/O device in 

devices for communication directly with the PLCs. Com- response to the request message. The request message and/or 

munication between the PLCs and the input and output the response message is hmited to a length that is less than 

communication devices can have yet another type of com- a TCP transaction length and/or a maximum transmission 

munication protocol which may require different types of 5Q unit limit, or both, depending on the embodiment of the 

input and output communication devices for each different present invention. 

type or brand of PLC. communications adapter (adapter or COM-adapter) 

The present invention is provided to solve these and other attaches to an input/output body as is described U.S. Pat. No. 

problems. 6,016,523 and/or German Patent No. DE 196 15 093, which 



SUMMARY OF THE INVENTION 



are hereby incorporated by reference. 

Specifically, the communications adapter is configured to 

The present invention is a communications adapter for directly attach to and communicate through at least an 

interfacing between MODBUS over Ethernet to TCP for the in-data port, the out-data port, and the identification port of 

communication of information between field devices and a the input/output body. In addition, the communications 

field master using these types of protocols. Field devices can 60 adapter is also configured to communicate with MODBUS 

include devices such as digital or binary inputs, digital or over Ethernet type field masters. The communications 

binary outputs, analog inputs, analog outputs, QPR units or adapter can have an input multiplexer for accepting data 

other special units, and INTIO devices to name only a few. from the in-data port and from the identification port, an 

Field masters can include programmable logic controllers output multiplexer for providing data to the out-data port, 

(PLCs) (sometimes referred to as process control devices or 65 and a processor for communicating with the input multi- 

PCDs), application specific controllers, and host computers/ plexor and the output multiplexor. The processor is also 

devices such as a personal computer with industrial auto- provided for converting the data, received from the input 
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multiplexor and the output multiplexor. Field bus circuitry is Modbus: Messaging application layer (Read/Write 

also connected between the processor and the field bus, services) 

within the communications adapter, for allowing the pro- TCP: transport layer for point to point 

cessor to communicate with the field master on the field bus. STP: Shielded Twisted Pair 

Alternatively, the communications adapter has at least one 5 The COM-adapter 10 is for providing an interface 

application specific integrated circuit (ASIC) for accepting between a master device 12 and an I/O device (body) 14 

data from the in-data port and from the identification port, havin g aa out P ut and/or an input. In the case of the I/O 

and for providing data to the out-data port. The ASIC ^vice 12 having an output, the adapter 10 has a TCP port 

converts the data to and from a MODBUS over Ethernet 16 coupling to the master device 12 via a transmission 

communications protocol of a PLC type of field master. 10 P ath 18 for giving a request message. The adapter 10 also 

y 3V has a connector 20 for operable coupling to the I/O device 

The present invention can take the form of a communi- 14 fof receiving lhe output 0 f the VO device 14. The adapter 

cations adapter adapted to only an input body or only an 10 further has an interface circuit 22 operably connected to 

output body having the same advantages and the full input/ the jq> ^ i$ arK j tnc connector 20 for transmitting a 

output body, as is understood with reference to the incor- response message over the transmission path 18 in response 

porated references above. Thus, the invention allows inex- 15 to the request message, the response message correlating to 

pensive standard network components to be used in place of the output received from the I/O device 14. The request 

specialized real time field bus components in communicat- message and the response message is limited to a length that 

ing with industrial sensor and actuator devices. This enables is less than a TCP transaction length and/or a maximum 

major savings in cost and complexity when connecting transmission unit limit, or both, depending on the embodi- 

simple devices to a network solution involving program- 20 ment of the present invention. 

mable controllers or other industrial computer systems, The selected TCP port in the COM-adapter should be TCP 

since the same networking infrastructure components can be port number 502 according to the design assumptions for 

shared. Other advantages and aspects of the present inven- one embodiment of the present invention, which are pro- 

tion will become apparent upon reading the following vided furmer below. In add idon, the assumptions also pro - 

description of the drawings and detailed description of the 25 vide that the interface circuitry ignores a connection request 

invention received over the transmission path by another TCP port. In 

addition, the interface circuitry discards a message^ of 

BRIEF DESCRIPTION OF THE DRAWINGS unknown meaning received by the TCP port. The interface 

TTif^ 1 • • c*u~ • 4/ + „*w~i., «,*«u circuitry closes the transaction path in response to an error 

FIG. lis a perspective view or the input/output body, with . ' . „_ ^ . « f 

4 . ■ a * f «uf - 30 received by the TCP port. In addition, the interf ace circuitry 

the communications adapter of the present invention - 4JJ v» , • r*_ » ™ ^ 

attached thereto transmits an Address Resolution Protocol Response over the 

^ . * , , . 1 , . , a ... , . transmission path if an Internet Protocol address encoded 

RG^isamcxlulantychartsijowingtheflexibihtyofthe ^ ^ messag£ matches m Imemet protoco] 

present invention. address associated with the I/O device. The interface cir- 

FIG. 3 is a block diagram of the internal structure of the 35 also transmits a connection confirmation in response 

present invention. to a TC p connection request. 

DETAILED DESCRIPTION The present invention also includes a method for provid- 
ing a connection between a master device 12 and an I/O 

While this invention is susceptible of embodiment in device 14 having an output and/or an input. In the case of the 

many different forms, there is shown in the drawings and ^ m ethod for providing a connection between a master device 

will herein be described in detail a preferred embodiment of and an t/q device having an output, the method includes 

the invention with the understanding that the present dis- receiving over a transmission path 18 a request message on 

closure is to be considered as an exemplification of the a preregistered TCP port 16 selected from a plurality of TCP 

principles of the invention and is not intended to limit the ports ^ method also includes receiving the output from 

broad aspect of the invention to the embodiments illustrated. 45 me y 0 device. The method further includes transmitting a 

With reference to FIG. 1, the present invention is a response message over the transmission path in response to 

communications adapter (COM-adapter) for connecting to the request message, the response message correlating to the 

and communicating with an input/output (I/O) body 2. The output of the I/O device 14. The request message and/or the 

I/O body 2 interfaces between field devices (not shown in response message is limited to a length that is less than both 

FIG. 1) and a field master (not shown in FIG. 1). The 50 a TCP transaction length and/or a maximum transmission 

communication adapter will allow an IO base (body) to um t limit, or both, depending on the embodiment of the 

reside on a Ethernet network and communicate using Mod- present invention. 

bus messages over the TCP/IP protocol. in the case of the method for providing a connection 

Some abbreviations for this specification can be defined between a master device 12 and an I/O device 14 having an 

as follows: 55 input, the method includes receiving over a transmission 

MIO: Momentum Terminal Input Output P ath 18 a request message on a preregistered TCP port 16 

ARP: Address Resolution Protocol used to get Ethernet sckrt«* from a plurality of TCP ports. The method also 

physical address, given the IP address includes transmitting a response message over the transmis- 

» mm f w , f ^ i . i t . _t sio n path in response to the request message. The method 

Mi-Interface: Momentum IO Internal Interface j* * *i_ • . r *i_ 

_ 60 further includes transmitting data to the input of the I/O 

BOOTP: Protocol used at power up to associate a MAC device u in response t0 the request message. The request 

address with an IP address message and/or the response message is limited to a length 

COM-adapter Communication Adapter that is less than a TCP transaction length and/or a maximum 

ICMP: Error indication and control protocol transmission unit limit, or both, depending on the embodi- 

I/O-body: Input/Output body (base unit) 65 ment of the present invention. 

IP: Internet network layer providing worldwide address- MODBUS is an industrial control protocol that is a 

ing capability widely-implemented standard where each transaction is 
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independent and comprises a request message and response 
message pair, each of bounded length. The length of the 
request and response messages is such that the encapsulated 
message, when sent as part of a standard TCP connection, is 
smaller than both the TCP 'window* and Maximum Trans- 5 
mission Unit (MTU) limits. In addition, because the 
response from a previous transaction must be received 
before the request for the next transaction may be sent, there 
is no reason to break up, or 'fragment* a MODBUS message 
when transmitted over TCP. The result is that there is a direct 10 
relationship between the MODBUS message encoding and 
the TCP frame encoding on any given network. 

By making a number of simplifying assumptions about 
the relationship between the target 'slave' device and its 
interrogating faster* device, the obligations of the receiv- 15 
ing software (See Appendix A) can be reduced from the 
traditional 'network protocol stack* consisting of a number 
of interacting software (See Appendix A) components to 
simpler 'state machine' where the correct response to an 
incoming request can be rapidly determined from the con- 20 
tent of the start of the request message. For one embodiment 
of the present invention, the following are the significant 
assumptions: 

All requests will be initiated at the 'master*. This means 
the slave has no need to initiate connections or resolve 25 
symbolic Domain Name Service (DNS) names. 

All requests will appear on registered TCP port number 
502, which is registered already with the Internet 
Assigned Numbers Authority (IANA) for the purpose 
of carrying MODBUS traffic. This means that 30 
attempted connection requests on other ports can be 
ignored. 

The slave may assume that a valid return path to the 
master is either 'direct* or can use the network bridge 
device which last processed the request message on its 35 
way to the device. This means that it is no necessary to 
maintain IP routing tables or understand ICMP redirect 
messages. 

It is appropriate if presented with a message of unknown 
meaning to discard the message as if the device is 40 
hiding behind a 'network firewall* device. 

The appropriate response to any MODBUS protocol or 
encoding error is to unilaterally close the TCP connec- 
tion. 

As a result, the MODBUS/TCP/Ethernet implementation, 45 
as an example, can implement largely pre-calculated 
responses to the following messages: 

Address Resolution Protocol (ARP) Request — send ARP 
response if IP address matches. 5Q 

Internet Control Management Protocol Echo (ICMP 
PING) request — send PING response (to aid in stan- 
dard network setup and troubleshooting). 

TCP connection request (SYN) — send connection con- 
firm (SYN ACK) if the requested port number is 502, 55 
ignore otherwise. 

TCP disconnect request (FIN) — send disconnect confirm 
(FIN ACK). 

MODBUS request as TCP data frame— send MODBUS 
response as TCP data frame, generating most of the $0 
protocol prefix information from the equivalent infor- 
mation in the request. 
As a result, performance is enhanced in at least two 
significant respects as compared to a traditional implemen- 
tation: 65 
The amount of network traffic is reduced because each 
MODBUS transaction involves typically 2 messages 



only (the encoded request and response). A traditional 
protocol stack would generate 4 messages (adding an 
ACK message for each data unit transmitted). This 
results in a saving of 20% to 50% of the network traffic, 
allowing the same network components to handle an 
additional 25% to 100% throughput with no additional 
cost. 

The calculation time at the slave is drastically reduced, 
allowing simpler and less expensive microprocessors to 
substitute for expensive ones and yet achieve the same 
effective response performance. At the same time, compat- 
ibility with conventional protocol stacks on large computers 
is maintained, because adherence to the standard encoding 
for MODBUS over TCP has not been violated. 

In the present invention, the Ethernet (MAC) address for 
the COM-adapter can be stored in flash memory. The 
COM-adapter can operate on a standard ethernet network 
that should include a BOOTP server. The IP address will be 
obtained from a network server using the BOOTP protocol. 
A commercially available BOOTP server can be used for 
this purpose. The COM-Adapter communicates using Mod- 
bus messages over TCP/IP to an NOE2X1 module, a host 
computer, or any device using the Modbus Protocol over 
Ethernet. The COM-adapter will be compatible with at least, 
host programs running over Windows 95, Windows NT, and 
UNIX TCP/IP stacks. The COM-adapter should meet the 
main international standards: U.L., C.SA, KM., and C.E. 
The COM-adapter enables the connection of all MIO Boards 
to the Ethernet. Used with the COM-adapter, the MIO will 
provide at least the following functions: communication 
using a limited set of Modbus commands over the TCP/IP 
protocol; input and output data exchanges; parameter man- 
agement (at initialization time and at run time); diagnostic 
information (LEDs, communications statistics); and down- 
loading of new operating software (See Appendix A) over 
the Ethernet connection. 

The external accesses to the Ethernet Co mm Adapter are: 
RJ45 female connector for lOBaseT network connection. 
2 LEDs: — Run: Green LED. Indicates the module's oper- 
ating state. — Communication: Green LED: Indicates 
network activity. 
The mode of operation is as follows: 
Initialization: at power up, a kernel firmware (see Appen- 
dix A, which is hereby incorporated herein by 
reference) will perform an internal initialization and 
self -tests. If the self tests fail, a run LED will flash, if 
possible, indicating a failure reason. In this state, the 
COM-adapter does not attempt to communicate over 
the network. If initialization is successful, the COM- 
adapter then requests its IP parameters (IP address, 
default gateway, and sub-net mask) using the BOOTP 
protocol over the Ethernet network and the MAC 
address stored in a nonvolatile memory. The COM- 
adapter will wait ten seconds for a BOOTP server to 
respond before trying again. The COM-adapter will 
retry six times, three times using the Ethernet II fram- 
ing type, and three times using the 802.2 SNAP header. 
If no server responds, the COM-adapter will use the last 
valid IP stored in flash memory. If no valid IP data 
exists, the COM-adapter will flash the run LED in a 
specified patten and retry the BOOTP request every 
thirty seconds. If the IP parameters are successfully 
obtained, the kernel (firmware) performs a checksum 
test on the executable image. If the image is invalid, the 
kernel will put the I/O base into a safe mode, flash the 
run LED with a pattern indicating its condition and wait 
for a download command sequence on the Ethernet 
port. 
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After receiving its network parameters, the COM-adapter 
runs an identification procedure with the I/O-body. If the 
Identification procedure fails, the Run LED flashes a failure 
code. 

When the initialization phase is successfully completed, 
the COM-adapter is ready to communicate using the Mod- 
bus protocol over TCP/IP. The Run LED will be on steady. 

The COM-adapter will enter the failed state if the I/OERR 
signal is pulled down by a complex I/O body for more than 
one second. If the I/OERR signal is pulled down by a simple 
I/O-Board, the COM-adapter remains in the ready state. The 
Run LED will indicate the failure condition and the I/O base 
will be forced into a safe state. 

With respect to downloading, at any time after success- 
fully obtaining its IP information, the COM-adapter will 
accept Modbus commands with function code 125 for 
downloading executive code. Downloading executive code 
should be understood in the art. When entering kernel 
software (See Appendix A), the unit will place the I/O in a 
safe state and enter the kernel. The Run LED will flash the 
code indicating that a download is in progress. During kernel 
downloading, only Modbus 125 commands will be 
accepted. When the download is complete, the COM- 
adapter will restart the initialization sequence. If the down- 
load fails, the unit will flash the LED sequence indicating 
that a download is required. 

The following describes the I/O operating modes. The 
COM-adapter will not support peer cop or global data. The 
COM-adapter has three groups of internal registers: module 
data, configuration, and status. All three register groups can 
be accessed over the Ethernet network by standard Modbus 
commands to ensure compatibility with existing devices 
(i.e., user logic MSTR block). The COM-adapter will 
restrict write access to the first node that communicates with 
it. The COM-adapter will maintain this lockout until com- 
munication with the master times out. The COM-adapter 
will allow the master to specify up to three other "owners" 
in order to facilitate the efficient implementation of hot 
standby systems. The user can access various registers to 
obtain I/O module information via the Ethernet network. 
These internal registers are mapped to emulate 4xxxx reg- 
isters allowing read/write 4xxxx register commands to be 
used (i.e. by using a MSTR block). 

Below is a Table to show data flow between the Ethernet 
network and the COM-adapter internal registers: 



-continued 



Read Only 



Module ASCII header 



FCOl 





Data Group 


Offset in Hex 


Size of Field 


Read Only 
Write Only 


Input Data 
Output Data 


0001 
0001 


Module 
dependent 

Module 
dependent 




Configuration Group 


Offset in Hex 


Size of Field 


Read/Write 
Read/Write 

Read/Write 
Read/Write 


Time-out Register 
Reserved for 
IO Distributed 
Ownership Register 
IP Parameter Save 
Register 


F001 
F201-F3FF 

F401 
F410 


1 word 
(See program 
listing). 
6 words 
3 word 




Status Group 


Offset in Hex 


Size of Field 


Read Only 


Status register 


F801 


word 1 of 



10 



IS 



20 



25 



30 



45 



50 



55 



60 



word 6 of 
status register 



status register 



Data group information is as follows: The input buffer 
scheme captures a snap shot of all input data The output 
buffer scheme insures that the newest copy of output data 
(only one buffer) is written to the output modules. A special 
algorithm is also used to insure old data is not lost, during 
a single word update of a multiple word output buffer field. 

Configuration group registers are as follows: The con- 
figuration group contains three registers that are used by the 
COM-adapter: a module hold-up time register, a write 
privilege register, and a save IP parameter register. A block 
of registers in this area is reserved for use by distributed I/O. 

Module hold-up: Module hold-up time-out is the amount 
of time the output modules are held in their current state 
without being updated by Modbus write commands. The 
module time-out is one word at offset FOOL This register can 
be read from and written to using Modbus commands, and 
the default value is 100 (1 sec). The module time-out word 
is in increments of 10 msec, with a minimum value of 30 
(300 msec) and a maximum value of 6,000 (60 sec). All 
values outside this range will be logged as illegal data 
address errors. Write access is restricted to the current 
"master." 

Another timer is the reservation time-out. The COM- 
adapter is dedicated to one Ethernet device. Reservation 
time-out is the amount of time (60 seconds) that the output 
module will be dedicated to an Ethernet device that is no 
longer communicating with it. If the time-out expires the 
COM-adapter will be dedicated to the next Ethernet device 
that writes to it If two Ethernet devices wanted to write data 
to the same COM-adapter, one Ethernet device would have 
to wait for the reservation time-out to expire before it could 
write its data. This time-out is a fixed value, preferably sixty 
seconds, and is not user accessible (not changeable). 

Ownership register: the Ownership register is used so that 
more than one Modbus device can have write access to the 
COM-adapter. Up to three remote Ethernet devices can have 
write access at the same time. This special case overrides the 
reservation time limit. Hie ownership register is six words 
starting at location F401, two words for the IP address of 
each Ethernet device. The default setting for each ownership 
register is zero (no owner). Register F401 contains the first 
owner's IP address, register F403 the second owner's IP 
address, and F405 contains the third owners IP address. All 
three owners have the same write privileges. A fourth 
controller (Ethernet device) could write to the COM-adapter 
if the three known owners (Ethernet devices) had ceased 
communication for more than the reservation time-out of 
sixty seconds. 

IP Parameter Save Register: this boolean register is 
located at offset F410 and determines the behavior of the 
COM-adapter if a BOOTP server is not found at initializa- 
tion time. If a one is written to the register, the current values 
of the IP parameters will be written to non-volatile storage 
(memory). If a BOOTP server cannot be found during the 
next initialization, these values will be used. If a zero is 
written to this register, any saved IP parameters will be 
erased. A change of state of this register will cause a reset of 
the COM-adapter. Writing the IP Parameter Save Register is 
restricted to owner or owners (Ethernet devices). 

MBP Status Group registers: there are two registers in the 
Status Group: The internal status register starts at offset 
F801, and the ASCII header register starts at offset FCOl. 
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Module (COM -Adapter) Status register 
The following table shows the contents of the Module 
status register: 



Words of 

information Description 



Ward 1 


Number of status words 


Max. of 13 words 


Word 2 


number of module input bytes 


Module dependent 


Word 3 


number of module output bytes 


Module dependent 


Word 4 


Module ID number 


Module dependent 


Word 5 


Module revision number 


XR 


Word 6 


ASCII header length in words 


Module dependent 


Word 7 


last node to communicate low 


IP Address 




word 




Word 8 


remaining reservation time 


X 


Word 9 


remaining module holdup time 


X 


Word 10 


Module health 


8000 hex - good health 


Word 11 


Last I/O module error 


X 


Word 12 


I/O module error counter 


X 


Word 13 


last node to communicate 


IP Address 



For the purpose of this chart: 

X=upper four bits reserved for station management 
commands, the upper 4 bits in this word will always be zero; 
R=(module revision number) REV 1.00=100 hex. 

ASCII header block: there is an ASCII header block 
starting at offset FC01. This header is used to give a brief 
description of the module. The length of this block can be 
between one to sixty-four bytes. The length is contained in 
word six of the status register. This area is read only. 

Compatibility: the COM -adapter is compatible to the 
ATI-interface and will function with all I/O bodies which 
operate according to the ATI -interface as described in U.S. 
patent application Ser. No. 09/036,565. 

MTBF quality specification: the mean time between fail- 
ure (MTBF) reliability calculation model is based on MIL_ 
HDBK-217 (a military standard). MTBF=l/failure rate. The 
specified value is calculated at 30 degrees C, GB (ground 
benign). The MTBF goal is 200,000 hours. 

Performance: the communication stack is optimized to get 
the best possible performance for Mod bus response time 
(time to issue a response after receiving a Modbus TCP 
request). The COM-adapter will support a MODBUS/TCP 
transaction rate of one per millisecond, providing a response 
to function code 23 for a simple 32 bit (2 word) in/out 
module in 500 micro-seconds. A master can recover from a 
TCP disruption by closing and reopening socket connection. 
This sequence will take no longer than 5 milliseconds due to 
delays at the COM-adapter. 

Electrical specifications: 

For the ATI-interface: 

Logic supply Vcc :5V/+-5%/500ma Max supplied from 
the I/O body to the interface., Levels, load, and timing will 
be according to other ATI-interface specifications. 

For the Ethernet-interface: 

Compliant with the STP 100 ohm connection. 



5 V Tolerance 

5 V Current Consumption 

Processor 

Memory 

Ethernet Controller 



+7-5% 

200 MA max.; @ < lOOuF Capacitive Load 
AMD186ER 

128K byte EPROM, 32K byte SRAM 
Crystal CS8900 



30 



35 



45 



50 



55 



60 



EMC Requirements: The COM-adapter should meet 
EMC tests described in the applicable standards. The COM- 
adapter is considered as open equipment, which means it 
should be within an enclosure. The following tests can be 
performed with shielded cable: 



TOP HAT 
(COM-adapter) 
OPEN 



10 



15 



20 



25 





Test 


Applicable 


EQUIPMENT 


Standard 


Description 


Port 


Para meters /Limits 


EN 55011 


Radiated 


Enclosure 


Class A 




Interference 






EN50140/ 


Radiated RF 


Enclosure 


80-1000 Mhz 


IEC 1000-4-3 


immunity 




10 V/m 


EN50140 


Radiated RF 


Enclosure 


900 Mhb 




impulse 




10 V/m 




immunity 






IEC 1000-4-2 


Electrostatic 


Enclosure 


8 kVAir 


Note 


Discharge 




4 kV contact 


ENV50141/ 


Conducted 


COM Port 


.15-80 MHz 


rEC 1000-4-6 


RF 




10 Vrms 


Note 1 


immunity 






ffiC 1000-4-4 


Fast 


Comm. 


1 kV cap. Clamp 




Transient 


lines 






Burst 






ENV 50142/ 


Surges 


Earth Port 


2 kVCM 


IEC1000-4-5 




(shield) 




IEC 1131 


Protective 


Connector 


30 A 


par 4.7.2 


Earth 


to 


<0.1 Ohms 


Continuity 


Earch 





Communication ports pass/fail criteria B is acceptable 
The COM-adapter should meet the following agency 
standards: 

U.L. 508, 746C, 94. 
IEC1131-2 (where applicable) 
CSA22.2 No. 142 
CE Mark 

FM Class 1 Div. 2 

The COM-adapter in operation should be kept within the 
following ranges: 



Temperature 


0-60 degrees C operating 




-40— (-85 degrees C. storage 


Humidity 


5-95% RH (non-condensing) 


Vibration 


10-57 Hz @ 0.075 mmda 




57-150 Hz @ 19 


Shock 


+/- 15 G peak, 11 ms, half sine-wave 



The COM-adapter can have 2 LEDs, and use Ethernet 
shielded or unshielded RJ45 female connector. Shielding 
should be provided on 360°, and good contacts should be 
provided with the external metallic parts of the RJ45 male 
connector. The Ethernet RJ45 pin out is: 

Pin 1: TX+ 

Pin 2: TX- 

Pin 3: RD+ 

Pin 4: RD- 

Modbus: the COM-adapter will accept MODBUS mes- 
sages over TCP/IP using the MBAP protocol to communi- 
cate with certain boards. Modbus function codes 9 (read 
registers), 16 (write multiple registers) and 23 (read/write) 
will be processed by the software (See Appendix A), which 
is attached hereto, and which is incorporated by reference 
herein, and passed to the ATI interface. Message 8, sub- 
function 21 (get/clear statistics), will return Ethernet statis- 
tics similar to the NOE2X1. Modbus 125 commands will be 
processed by the kernel for executive download. The COM- 
adapter will respond to all other Modbus messages with 
exception code 01 (illegal function). 

TCP/IP: the COM-adapter will run an optimized commu- 
nication stack. This stack will enable the COM-adapter to 
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respond to Modbus messages with minimum turn around 
time. It must also handle other network traffic, such as ARP 
requests and ICMP echo requests, in a manner consistent 
with the associated protocols. The COM -adapter will 
receive its network parameters from a BOOTP type server or 
use those retained in nonvolatile storage, if available. 

The Modbus handler will field requests from the network 
and either respond directly or pass the request to the ATI 
interface. The handler will maintain the internal configura- 
tion and status registers, and arbitrate write access to the 
COM-adapter. 10 

The TCP/IP communication stack should be optimized for 
performance. However, these optimizations should not 
impair its ability to function as a standard TCP/IP node on 
an integrated network. 

The kernel will provide basic services for the operation of 
the unit. These include timer services, resource 1 
management, interrupt handling and drivers for peripherals 
such as Ethernet controller. Initialization and fault handling 
will also be handled by this code. 

The present application is being filed contemporaneously 
with a U.S. Patent Application Attorney Docket No. 401 P 20 
129, both of which are, or will be, assigned to Schneider 
Automation, which other application is incorporated herein 
by reference to the extent necessary for the understanding of 
the present invention. 

While the specific embodiments have been illustrated and is 
described, numerous modifications come to mind without 
significantly departing from the spirit of the invention and 
the scope of protection is only limited by the scope of the 
accompanying claims. 

We claim: 30 

1. A method for providing a connection between a master 
device having a first protocol and an I/O device having a 
second protocol and an output, the method comprising the 
steps of: 

receiving over a transmission path a request message on 35 
a preregistered TCP port selected from a plurality of 
TCP ports; 

receiving the output from the I/O device; 

transmitting a response message from the I/O device over 
the transmission path in response to the request 49 
message, the response message correlating to the out- 
put of the I/O device; and 

limiting the request message and the response message to 
a length that is less than both a TCP transaction length 
and a maximum transmission unit limit and wherein an 45 
adapter operably connected between the master device 
and the I/O device converts the request and response 
messages to and from the protocols of the respective 
master and I/O devices. 

2. The method of claim 1, further including the step of 50 
receiving the input request message on a TCP port number 
502. 

3. The method of claim 1, further including the step of 
ignoring a connection request received from a device other 
than the master device. 5S 

4. The method of claim 1, further including the step of 
discarding a message of unknown meaning received over the 
transmission path. 

5. The method of claim 1, further including the step of 
closing the transaction path in response to an error. 

6. The method of claim 1, further including the step of 60 
sending an address resolution protocol response if an inter- 
net protocol address encoded within the request message 
matches an internet protocol address associated with the I/O 
device. 

7. The method of claim 1, further including the step of 65 
sending a connection confirmation over the transmission 
path in response to a TCP connection request. 
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8. An adapter for providing an interface between a master 
device and an I/O device having an output, the adapter 
comprising: 

a TCP port for coupling to the master device via a 
transmission path for receiving a request message; 

a connector for operable coupling to the I/O device for 
receiving the output of the I/O device; and, 

an interface circuit operably connected to the TCP port 
and the connector for transmitting a response message 
from the I/O device over the transmission path in 
response to the request message, the response message 
correlating to the output received from the I/O device 
is converted for communication with the master device 
and wherein the request message and the response 
message is limited to a length that is less than both a 
TCP transaction length and a maximum transmission 
unit limit. 

9. The adapter of claim 8, wherein the TCP port is TCP 
port number 502. 

10. The adapter of claim 8, wherein the interface circuitry 
ignores a connection request received over the transmission 
path by another TCP port. 

11. The adapter of claim 8, wherein the interface circuitry 
discards a message of unknown meaning received by the 
TCP port. 

12. The adapter of claim 8, wherein the interface circuitry 
closes the transaction path in response to an error received 
by the TCP port. 

13. The adapter of claim 8, wherein the interface circuitry 
transmits an address resolution protocol response over the 
transmission path if an internet protocol address encoded 
with the request message matches an internet protocol 
address associated with the I/O device. 

14. The adapter of claim 8, wherein the interface circuitry 
transmits a connection confirmation in response to a TCP 
connection request. 

15. A method for providing a connection between a master 
device and an I/O device having an input, the method 
comprising the steps of: 

receiving over a transmission path a request message on 
a preregistered TCP port selected from a plurality of 
TCP ports; 

transmitting a response message from the I/O device over 
the transmission path in response to the request mes- 
sage; 

transmitting data from the master device to the input of 
the I/O device in response to the request message, the 
data being converted for communication with the I/O 
device; and 

limiting the request message and the response message to 
a length that is less than a TCP transaction length and 
a maximum transmission unit limit. 

16. The method of claim 15, further including the steps of 
ignoring a connection request received from a device other 
than the master device, discarding a message of unknown 
meaning received over the transmission path, and closing 
the transaction path in response to a transmission error. 

17. The method of claim 15, further including the step of 
sending an address resolution protocol response if an inter- 
net protocol address encoded within the request message 
matches an Internet Protocol address associated with the I/O 
device. 

18. The method of claim 15, further including the step of 
sending a connection confirmation over the transmission 
path in response to a TCP connection request. 
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